Inter-gadget communication

ABSTRACT

Disclosed is an inter-gadget communication architecture or framework that allows information from different sources to be independently viewed or correlated from within a browser. The inter-gadget communication architecture or framework comprises gadgets or iFrames, which communicate or interact with other gadgets on the displayed page by accessing other iFrames/gadgets on the same web page. The inter-gadget communication architecture or framework allows gadgets to be vendor application agnostic, providing platform independence.

BACKGROUND

The present invention relates to inter-gadget communication that allowselectronic information from different sources to be independently viewedor correlated from within a browser.

The Department of Defense (DoD) and US government intelligence agenciesprocess large amounts of electronic information. Traditionally,dissemination, handling, and correlation of electronic information isdone manually. For instance, electronic information from a first sourcemay be presented in one format, while electronic information from asecond source may be presented in a different format. The only way tocombine the electronic information from the two sources is to manuallycorrelate the data from the two sources. Also, many conventionalelectronic solutions have vendor constraints, which prevent combiningsource information.

In particular, the industry has tried to address part of the informationcorrelation problem using portals. Major vendors such as BEA and IBM,for example, have developed portlet-to-portlet communication to permittwo different sources to communicate via portlets. However, eachvendor's portlets only communicate within that vendor's portal. Inaddition, gadgets have been developed by such organizations as Google,Microsoft, and Apple Computer, for example. Gadgets are small objectsthat allow dynamic content to be placed on a web page.

A mashup is a web application hybrid that combines data from more thanone source into a single integrated tool. Thus, a mashup combines datafrom different sources in one place using JavaScript. A mashup does notinvolve simple embedding of data from another site to form a compounddocument. An example, cartographic data from Google Maps™, for example,may be used to add location information to real-estate data, therebycreating a new and distinct web service that was not originally providedby either source.

Content used in mashups is typically sourced from a third party via apublic interface, application programming interface (API) or webservice. The architecture of mashup web applications always has threeparts. The first part is the content provider, which is the source ofthe data. Data is made available using an application programminginterface (API) and different Web-protocols such as RSS, REST, and WebService, for example. The second part is the mashup site. The mashupsite comprises the web application that provides the new service usingdifferent data sources that are not owned by it. The third part is theclient web browser. The client web browser is the user interface of themashup. In a web-application, the content can be mashed by the clientweb browser using a client-side web language, such as JavaScript.

It would be desirable to have an inter-gadget communication frameworkthat provides for an improved way to mash up the data derived frommultiple sources. It would be desirable to have inter-gadgetcommunications that provides an open way to correlate and viewinformation from differing sources independent of vendor deployedsolutions.

BRIEF DESCRIPTION OF THE DRAWINGS

The various features and advantages of the present invention may be morereadily understood with reference to the following detailed descriptiontaken in conjunction with the accompanying drawings, wherein likereference numerals designate like structural elements, and in which:

FIG. 1 illustrates a system implementing an exemplary inter-gadgetcommunications architecture or framework;

FIG. 2 illustrates the flow of IGC object gadgets;

FIG. 3 illustrates an exemplary IGC object of a producing gadget;

FIG. 4 illustrates exemplary consumer gadget calling methods of an IGCobject;

FIG. 5 illustrates passing of data between gadget iFrames;

FIG. 6 illustrates exemplary gadgets that may be used in the exemplaryinter-gadget communications architecture or framework;

FIG. 7 illustrates several gadgets integrated on a web page using theexemplary inter-gadget communications architecture or framework;

FIG. 8 is a block diagram that illustrates inter-gadget communicationwithin a web page displayed in a browser; and

FIG. 9 pictorially illustrates exemplary inter-gadget communicationsbetween GeoRSS and Google Maps.

DETAILED DESCRIPTION

Referring now to FIG. 1, it illustrates an exemplary inter-gadgetcommunication (IGC) architecture 10 or framework 10. The inter-gadgetcommunications architecture 10 or framework 10 permits correlation andviewing of information derived from different sources.

The exemplary inter-gadget communications architecture 10 or framework10 comprises a browser 11 that runs on a computing device 12 having adisplay 13. The computing device 12 may be a personal computer, a laptopcomputer, a personal digital assistant (PDA), or a cellular device, forexample. The computing device 12 is connected to various sources ofinformation or data, such as one or more application servers 14, andother external services 14 a, coupled to the computing device 12 via anetwork 15 or the internet 15. The computing device 12 communicates withthe application servers 14, or external services 14 a, using servlets.The computing device 12 communicates with the browser 11 using an http(hypertext transfer protocol), and over the network 15 using anhttp-SOAP protocol (hypertext transfer protocol, simple object accessprotocol).

The exemplary inter-gadget communication architecture 10 or framework 10allows information from different sources 14 to be independently viewedor correlated within the browser 11. The inter-gadget communicationarchitecture 10 or framework 10 comprises a plurality of gadgets 16 thatare displayed within the browser 11 and allows data to be communicatedbetween and shared by the gadgets 16. FIGS. 2-5 illustrate detailsrelating to this.

FIG. 2 illustrates the flow of IGC objects between gadgets 16, FIG. 3illustrates an exemplary IGC object 18 of a producing gadget 16, FIG. 4illustrates exemplary consumer gadget snippet code calling methods of anIGC object, and FIG. 5 illustrates passing of data between gadgetiFrames 17. All gadgets 16 exist inside different iFrames 17 on a webpage displayed within the browser 11. When each gadget 16 is createdinside the gadget framework 10, an iFrame 17 with unique session ID iscreated with contents provided via a Uniform Resource Locator (URL). Bydefault to Hypertext Markup Language (HTML) and browser standards, theweb page holds the current state of all frames (including iFrames 17)residing on it. These frames can be accessed from a frames object array,using the unique session ID of each iFrame 17 created by theinter-gadget framework 10.

Gadgets 16 and their iFrames 17 have their own object and variablespace, separate from the main web page. Gadgets 16 can call JavaScriptmethods in the object space of other gadgets 16 via the frames objectarray of the web page as long as the contents of the gadgets 16 and theframework 10 reside in the same domain and as long as the gadget 16 isable to point to that specific frame object 18 of the other gadget 16from the frames array. Methods such as the following can thus beaccessed:

-   -   iframeObject.method (param1, param2, etc.).        When calling these methods, data are passed from one gadget 16        to another as parameters. The inter-gadget framework 10 and the        IGC architecture 10 deal with communication of data between        gadget iFrames 17 by controlling the session IDs of the frame        objects 18 on the web page and by passing IGC objects 18 between        gadgets 16. Not all gadgets 16 have an IGC object 18, but for        those that do, their IGC object 18 contains all necessary        exposed methods that other gadgets 16 can call upon and pass        data to.

The inter-gadget communications architecture 10 or framework 10 providesthe look, feel and experience of a personal computer desktop. Theinter-gadget communications architecture 10 or framework 10 allowsimporting of and collaboration between gadgets 16, such as iGooglegadgets, widgets, and other third party gadgets. New gadgets 16 may becreated using a JavaScript application programming interface (API) ofthe architecture 10 or framework 10.

As mentioned above, each gadget 16 that participates in inter-gadgetcommunication has an IGC object 18 (FIG. 3). Gadgets 16 can either beproducers of inter-gadget communication, consumers of inter-gadgetcommunication, or both. As a consumer of inter-gadget communication,when a gadget 16 is developed it must include the provided JavaScriptAPI available from the framework 10 and therefore be able to consume anyavailable predefined IGC objects 18 from other gadgets 16 by using aspecific gadgetLibraryId or igcCategoryId of the gadget 16 or gadgets 16it wishes to connect with. Any gadget 16 written in any form orlanguage, including RIA (Rich Internet Application), must be able tointerface with JavaScript for inter-gadget communication to work.Therefore, developers or authors of pre-existing gadgets (iGoogle,Netvibes, etc.) can add the necessary code to include the IGC API anduse it. If an author or developer wishes to make a pre-existing gadget16 a producer of inter-gadget communication, where other gadgets 16 canconsume its IGC object 18 and pass data along to it, they would create aJavaScript IGC object 18 with exposed methods and a set of parameterssuch as is shown in FIG. 3, for example. These exposed JavaScriptmethods can then internally call the necessary internal or privatemethods of that gadget 16. The inter-gadget communications architecture10 or framework 10 provides a repository for discovery and distributionof gadgets 16.

Gadgets 16, such as mini-applications, portlets, or widgets, and thelike, are browser-based interfaces for services and information. Everygadget will be uniquely identified in the repository with apre-generated gadgetLibraryId that gets assigned whenever a new gadgetis submitted. Exemplary gadgets 16 may comprise RSS feeds, DistributedCommon Ground System Integration Backbone (DCGS-DIB) services,Extensible Markup Language (XML) services, Keyhole Markup Language (KML)services, Google Earth™ services, Virtual Earth™ services, or access tomission data, and the like. The gadgets 16 are developed using standardssimilar to those used by Google, Microsoft and others. The gadgets 16provide interoperability with services provided by Websphere, Weblogic,SharePoint and JBoss, for example.

Many types of gadgets 16 developed today can operate in different webpages or portals, as long as they are developed using web standards. Themini-application front-end of the gadget 16 can be used in any web form.However, in order to use the added capability of inter-gadgetcommunication, the gadgets 16 need to be placed in a framework 10 thatsupports and works with the IGC API. Existing portal investment anddevelopment is thus preserved using the inter-gadget communicationsarchitecture 10 or framework 10.

FIG. 6 illustrates exemplary gadgets 16 that may be used in andprocessed by the exemplary inter-gadget communications architecture 10or framework 10. FIG. 7 illustrates multiple gadgets 16 integrated on asingle web page using the exemplary inter-gadget communicationsarchitecture 10 or framework 10. FIG. 8 illustrates inter-gadgetcommunication within a web page displayed in the browser 11.

The inter-gadget communications architecture 10 or framework 10 providesfor a web page or application that integrates complementary elementsfrom two or more sources 14, 14 a. Gadgets 16 can display data orconnect with sources 14 or services 14 a in any way or form as theywish. Once the data is available on the gadget 16, using inter-gadgetcommunication, it can pass along that data to other gadgets 16 on theweb page that may or may not be connected to other sources 14 orservices 14 a on their own. Therefore, data from multiple sources 14, 14a can thus be put together on the client side using inter-gadgetcommunication. The web page or application may be created using Ajax(Asynchronous Javascript and XML) web development techniques, forexample. The inter-gadget communications architecture 10 or framework 10allows two or more gadgets 16 to interact with each other by sharingcomplementary data.

The inter-gadget communications architecture 10 or framework 10 is acomplement to the currently-available Ajax framework. Client-sidecommunication is accomplished using inter-gadget communication. Thegadget framework 10 handles the transaction of IGC objects 18 betweengadget iFrames 17. While each gadget 16 may obtain data from a server 14or service 14 a, the IGC data layer occurs all on the client side.

Data communicated between gadgets 16 may include latitude and longitudedata, ship identification numbers, or similar data. For example, theinter-gadget communications architecture 10 or framework 10 may embodygeospatial gadgets 16. Such geospatial gadgets 16 have map plottingcapabilities, allowing point plotting, line plotting and plot shaping.Thus, existing plotting capabilities may be displayed using theapplication programming interface (API).

Other gadgets 16 may include RSS feeds, signal data and XML data, andthe like. Using the inter-gadget communications architecture 10 orframework 10, all such gadgets can call exposed plotting methods to anygeospatial gadget. Any RSS, signal, or XML data that has geospatialcoordinates can then be passed on to any geospatial gadget 16 andplotted accordingly within the inter-gadget communications architecture10 or framework 10.

Thus, the browser 11 is configured to process and display gadgets 16.The gadgets 16 employed in the inter-gadget communications architecture10 or framework 10 are different from conventional gadgets. Each gadget16 is a standalone element that is displayed in the browser 11. Thegadgets 16 are vendor application agnostic in the inter-gadgetcommunication architecture 10 or framework 10, thus providing platformindependence. Gadgets 16 are comprised of Hypertext Markup Language(HTML) or JavaScript code employing Asynchronous JavaScript and XML(AJAX) requests to get data, or Java Server Pages (JSP) content toacquire data from a server 14, which data are presented in the browser11.

As long as the gadgets 16 are written using web standards, they shouldbe similar to conventional web 2.0 gadgets already in existence. A majordifference is that each gadget's contents 16 can be run in a separateweb page, and thus can be minimized to take form inside an iFrame 17 ofsmaller size in the framework 10. Also, the included JavaScript IGC APIand code adds additional functionality that conventional gadgets do nothave.

Referring to FIG. 9, in the inter-gadget architecture 10 or framework 10several gadgets 16 are brought together on a single HTML page usingiFrames 17. FIG. 9 shows two inter-communicating gadgets 16 at the upperleft portion of the browser window that communicate with each otherusing inter-gadget communications, and three intercommunicating gadgets16 at the lower right portion of the browser window wherein two gadgets16 intercommunicate with a third gadget 16. HTML provides the ability tosplit a content window of the browser 11 into several frames. Each ofthe iFrames 17 comprises a window of its own within the content window(i.e., the main window of the browser 11). The iFrame 17 is an inlineframe that contains a completely separate web page with its own URL(i.e., the gadget 16).

The gadget framework 10 is configured so that it is aware of all uniquesession IDs assigned to each gadget iFrame 17, since the framework 10creates the iFrames 17 when the gadgets 16 load and assigns a unique ID.When a gadget 16 is requesting to call exposed methods of another gadget16, the framework 10 can get the iFrame object 18 of the correspondinggadget 16 from the frames array. Once the iFrame object 18 is obtained,the exposed methods can be called from within. Gadgets 16 that haveexposed methods for other gadgets 16 to use will wrap and include thesemethods and their parameters inside an IGC (JavaScript) object 18. Whentwo or more gadgets 16 link together through the framework 10, theframework 10 grabs the corresponding IGC objects 18 from the producergadgets 16 and sends them out to the consumer gadgets 16.

All gadgets 16 that use inter-gadget communications preferably includethe following JavaScript files available from the gadget framework 10:“/fw/lib/Prototype/1.6.0.2/prototype.js” and “/fw/api/js/fwapi.js”. Theinter-gadget communications JavaScript files include basic hash mapfunctionality as well as the following objects to be used for IGC by thegadgets or internally by the framework 10:

igcObjectHash, which is a hash map with a name-value pair linking gadgetsession IDs of currently linked gadgets with their IGC objects;

igcGadgetSpecificHash, which is a hash map with a name-value pairlinking gadget Library IDs with an array of gadget session IDs ofcurrently linked gadgets;

igcCategoryHash, which is a hash map with a name-value pair linking IGCcategory IDs with an array of gadget session IDs of currently linkedgadgets;

register: function ( ), which registers the gadget inside Framework;

linkGadget: function (gadgetSessionId), which links the gadget to agadget with an ID of gadgetSessionId and stores its igcObject inside theigcObject hash map;

unregister: function ( ), which unregisters the gadget from theFramework;

unlinkGadget: function (gadgetSessionId), which unlinks the gadget fromgadget with an ID of gadgetSessionId and removes the appropriateigcObjects from the hash map; and

getIgc: function (TYPE, igcId), which returns an array of igcObjects ofall currently linked gadgets with either gadgetLibraryId==igcId (ifTYPE==“GADGET”) or with IGC producer category Id==igcId (ifTYPE==“CATEGORY”).

The functions and objects listed above are part of the exposed API thatthe framework 10 provides to all gadgets 16. Once the gadget 16 includesthe reference to the API, it can call any of these methods. Only two ofthese methods (register and getIgc) are to be used by gadget developers,while the rest of the methods are used internally by the framework. Whenthe gadget 16 contents are loaded in the web page, the gadget 16 callsthe register( ) function to register in the framework 10. Onceregistered, a user may automatically or manually link the gadget 16 toanother gadget 16. If acceptable, the framework linking processinternally calls the linkGadget( ) function to link the two gadgets 16and the IGC objects 18. When two gadgets 16 link, the framework 10 getsall corresponding IGC objects 18 from all the linked producer gadgets 16and sends them to all the linked corresponding consumer gadgets 16. Theunregister( ) and unlinkGadget( ) functions, called internally by theframework, do the opposite and remove the IGC functionality.IgcObjectHash, igcGadgetSpecificHash, and igcCategoryHash are threevariables referencing hash maps that correspond to retrieving all IGCobjects 18 of all the gadgets 16 that a gadget 16 is currently linkedto. The function getIgc( ) is used to retrieve the necessary IGC object18 and call any of the included exposed methods to pass along data.

Pertinent attributes of inter-gadget communications are that (1) agadget 16 is known as a producer of inter-gadget communications and aconsumer of inter-gadget communications; (2) as a producer, a gadget 16contains an IGC object 18 that the framework 10 can access and send toother gadgets 16 that register and link as consumers; (3) gadgets 16 canconsume IGC objects 18 of a specific gadget 16 (via a gadget UniversallyUnique Identifier or UUID) or of a specific IGC category (via IGCcategory UUID); (4) all IGC objects 18 of a specific category UUID havethe same exposed methods (including the same parameters).

Once a gadget 16 is developed, it can be submitted to a gadget libraryor repository which will retain all necessary metadata for that gadget16. This metadata can include gadget size, author details, category,etc. The majority of the metadata is based on the Netvibes Widgets 1.0proposal and Google GModule Gadget specifications that have already beenestablished. In addition to this metadata, the IGC attributes requiredfor the framework 10 to use are also included. These IGC attributesdetermine whether a gadget 16 is a producer, consumer, or both. Also,they determine which gadgets 16 it will be able to link to via IGC. Oncethe gadget 16 is submitted, a UUID for the gadget, known as the GadgetLibrary ID, is then generated automatically by the server. This UUIDdefines this specific gadget 16 in the gadget repository or library, andany other gadget 16 that wishes to link to it will use this UUID as itsIGC attributes. This UUID is different than the Gadget Session ID, whichis a UUID that gets generated dynamically by the framework when a gadgetis created on the web page once the user selects a gadget from therepository or library. If the gadget 16 belongs to an IGC category,where the exposed methods are pre-defined, then other gadgets 16 areable to link to it using the pre-existing IGC category UUID. This UUIDis also generated automatically, but only each time a new IGC categorygets created. The inter-gadget communications attributes for a gadget 16are as follows:

Producer:

-   -   Gadget Library ID: (Library UUID of the gadget would be        populated here if gadget produces an IGC object not belonging to        an IGC category)    -   IGC Category ID: (UUIDs of IGC categories populated here if        gadget produces    -   IGC objects belonging to IGC categories of gadgets)

Consumer:

-   -   Gadget Library ID: (Library UUIDs populated here if gadget        consumes IGC objects of those gadgets with Library IDs)    -   IGC Category ID=(UUIDs of IGC categories populated here if        gadget consumes IGC objects belonging to IGC categories of        gadgets)

The rest of the gadget attributes, based upon the Netvibes Widgets 1.0W3C and Google GModule Gadget specifications include: LibraryId (UUIDgenerated by back-end to identify specific gadget in entire listing orlibrary); SessionId (UUID generated by back-end to identify specificgadget generated on web page); Width; Height; Url; Description; Icon(link); Thumbnail (link); Image (link); Author (Optional) includingName, Organization, Email and Link.

Whenever a gadget 16 is developed, an IGC object 18 is written for theframework 10 to send out to other gadgets 16. The new IGC object 18includes all necessary methods that are exposed for other gadgets 16 tocall upon and pass data through. An exemplary IGC object 18 has theform:

var Igc={

-   -   exposedMethod1 (parameter1, parameter2, etc.)    -   exposedMethod2 (parameter1, parameter2, etc.)    -   Etc.

}

An IGC category of gadgets 16 has similar generic methods exposed. Forexample, all map plotting gadgets have Igc.plotPoint(latitude,longitude) and Igc.plotLine(latitudeArray[ ], longitudeArray[ ]) astheir exposed methods. All gadgets 16 that adhere to a single categoryof inter-gadget communications, as opposed to being gadget specific,have the same exposed methods and parameters.

An exemplary IGC object 18 for a Google map gadget 16 is as follows:

var Igc={

-   -   plotPoint: function (name, infoContent, latitude, longitude,        iconUrl)    -   {        -   /*internal code */    -   }    -   plotLine: function (name, infoContent, latitudes, longitudes,        color)    -   {        -   /*internal code */    -   }    -   plotPolygon: function (name, infoContent, latitudes, longitudes,        color)    -   {        -   /*internal code */    -   }

}

Exemplary calling methods of an IGC object 18 are as follows.

Whenever a gadget 16 is developed, code is written to call exposedmethods of other gadgets 16 using the provided JavaScript API of thegadget framework 10. This code may be formatted in the same fashion asis shown in FIG. 4.

When the contents of a gadget 16 load onto the HTML page, an API call ismade to register the gadget 16 within the framework 10, i.e.:

com.lmco.sj.fw.api.igc.register( ).

Once, the linking event process is triggered, an IGC object 18 is sentby the framework 10 that includes all necessary exposed methods.

The IGC object 18 is then added into the gadget's igcObject hash map andcan be accessed using either the IGC Category ID or the Gadget LibraryID for later retrieval:

com.lmco.sj.fw.api.igc.getIgc(TYPE, igcId).

An exemplary IGC object retrieval process will now be described. Anexemplary process for retrieving an IGC object 18 and calling itsexposed method is as follows. This flow of IGC object retrieval isactually done by the gadget framework internally, while the developer ofthe consumer gadget would only have to reference the getIgc( )methodmentioned above. Reference is made to the three hash maps below. First,the gadget framework must get the session IDs of all currently linkedgadgets for either a specific IGC category or single IGC gadget 16:

This makes a call to one of two intermediate Hash Maps that return anarray of gadgetSessionlds of all currently linked gadgets with either:

A) gadgetLibraryId=igcId (if type=“GADGET”)

B) igc producer category==igcId (if type=“CATEGORY”)

Gadget Library Hash:

Gadget Library ID Gadget Session IDs gadgetLibId_0 [gadgetSessionId_0,gadgetSessionId_1, gadgetSessionId, . . . ] gadgetLibId_1[gadgetSessionId_0, gadgetSessionId_1, gadgetSessionId, . . . ] . . . .. .

IGC Category Hash:

Gadget Library ID Gadget Session IDs igcCategoryId_0 [gadgetSessionId_0,gadgetSessionId_1, gadgetSessionId_2, . . . ] igcCategoryId_1[gadgetSessionId_0, gadgetSessionId_1, gadgetSessionId_2, . . . ] . . .. . .

Once the gadgetSessionlds are known, the igcObject can get retrievedfrom the igcObject hash map. This makes a call to a final Hash Map thatreturns IGC object for a specific gadget with now known sessionId.

IGC Object Hash:

Gadget Session ID IGC Object gadgetSessionId_0 Igc = {  method1:function ( . . . ) { . . . }  method2: function ( . . . ) { . . . } . .. } gadgetSessionId_1 Igc = {  method1: function ( . . . ) { . . . } method2: function ( . . . ) { . . . } . . . } . . . . . .

An exemplary IGC object 18 used by a GeoRSS gadget 16 is as follows:

-   -   IGC Category ID for map plotting category of gadgets:        “map-plot-category1”, linked Google Map gadget with        LibraryId=“google-map-lib1” and        SessionId=“google-map-session004”. GeoRSS gadget must get IGC        object of currently linked Google Map gadget:        -   com.lmco.sj.fw.api.igc.getIgc (“CATEGORY”,            “map-plot-category1”)        -   returns [IGC object of Google Map gadget with            sessionId=“google-map-session004”].

While in actuality a total of three hash maps are used to retrieve theIGC object 18, from a higher level it is like one hash map. This“single” hash map is for the IGC objects 18 of the GeoRSS gadget 16 andconceptually looks like this:

IgcId (TYPE = CATEGORY) IGC Object map-plot-category1 Igc = { plotPoint: function ( . . . ) { . . . }  plotLine: function ( . . . ) {. . . }  plotPolygon: function ( . . . ) { . . . } }

From within the returned igcObject, the Geo RSS gadget can call theexposed Google Map gadget methods, and pass the proper parameters, forexample:

Igc.plotPoint(name, htmlContent, latitude, longitude).

Exemplary inter-gadget communications between GeoRSS and Google Maps ispictorially illustrated in FIG. 9. A GeoRSS gadget 16 in an iFrame 17having gadgetLibraryId=“geo-rss-lib1” and sessionId=“geo-rss-session012”communicates with a Google Map gadget 16 in an iFrame 17 havinggadgetLibraryId=“google-map-lib1” and sessionId=“google-map-session004”using the inter-gadget communications object Igc.plotPoint(name,htmlContent, latitude, longitude).

The IGC attributes of the Google Map gadget 16 in the iFrame 17 are:

Producer:

-   -   Gadget Library ID=“google-map-lib1” (UUID for Google Map Gadget)    -   IGC Category ID=“map-plot-category1” (UUID for map plotting        category of gadgets 16)

Consumer:

-   -   Gadget Library ID=[None]    -   IGC Category ID=[None]

The IGC attributes of the GeoRSS gadget 16 in the iFrame 17 are:

Producer:

-   -   Gadget Library ID=[None]    -   IGC Category ID=[None]

Consumer:

-   -   Gadget Library ID=[None]    -   IGC Category ID=“map-plot-category1” (UUID for map plotting        category of gadgets 16)

The IgcObject hash map is:

Gadget Session ID IGC Object google-map-session004 Igc = {  plotPoint:function ( . . . ) { . . . }  plotLine: function ( . . . ) { . . . } plotPolygon: function ( . . . ) { . . . } }

The size of the iFrame 17 may be specified in the surrounding HTML page,so that the surrounding web page can be presented in the browser 11while the iFrame 17 is being loaded. Thus, when an iFrame 17 isgenerated by the web page, several attributes can be specified: URL tothe contents, size of the iFrame 17, and unique session ID or name forthe iFrame 17. An iFrame 17 can thus be of specific size and take uponly part of the web page. The iFrame 17 will also have a library ID andpoint to a unique URL, all provided by the metadata in the back-end. TheiFrame 17 behaves much like an inline image and the user can scroll itout of view. The iFrame 17 can also contain its own scroll bar,independent of the scroll bar of the surrounding web page.

Each gadget 16 may be an iFrame 17, which can communicate or interactwith other gadgets 16 on the same web page by accessing other iFrames17/gadgets 16 on the same web page. When a new gadget 16 is added to aweb page, a new iFrame 17 is generated through a W3C Document ObjectModel (DOM). Thus, when a gadget 16 is dragged into the web page, thegadget framework 10 generates the gadget 16, including the correspondingiFrame 17, according to the attributes given from the gadget repositoryor library. Each gadget 16 has a predefined library UUID that maps to aspecific gadget listing in the gadget repository or library. Theframework 10 simply creates a DIV HTML element for each gadget 16, whichincludes all necessary attributes and appropriate iFrame 17 with newlygenerated session UUID. Each iFrame 17 or gadget 16 holds separate HTMLcontent with JavaScript.

The inter-gadget communication architecture 10 or framework 10 thusembodies gadgets 16 that export specific methods that can be used byother gadgets 16. By allowing other gadgets 16 to call these exportedmethods directly on the HTML DOM layer, data can be passed betweendifferent gadgets 16. Gadgets 16 can therefore asynchronously pull datafrom different sources and web services, and through the inter-gadgetcommunication architecture 10 or framework 10, the data can mash-up onthe client-side of the browser 11. Gadget developers can then export newmethods (produce IGC) for other gadgets 16 to call upon or use availablemethod calls (consumer of IGC) exported by other gadgets 16 in order toeither receive or send their data for mashing up.

Thus, an inter-gadget communication architecture or framework has beendisclosed that allows information from different sources to be viewedindependently, or correlated, from within a browser. It is to beunderstood that the above-described embodiments are merely illustrativeof some of the many specific embodiments that represent applications ofthe principles discussed above. Clearly, numerous and other arrangementscan be readily devised by those skilled in the art without departingfrom the scope of the invention.

What is claimed is:
 1. Computing apparatus, comprising: a computingdevice coupled with one or more servers and database via a network; andan inter-gadget communication (IGC) framework having a browser that runson the computing device and that comprises software code that displays aplurality of gadgets on a single web page, and the software code thatcommunicates and shares data between the plurality of gadgets, each ofthe gadgets including an iFrame object with a unique session ID that isgenerated dynamically by the inter-gadget communication framework, and agadget library ID that is generated automatically by one of the servers.2. The apparatus recited in claim 1 wherein the computing devicecomprises a personal computer.
 3. The apparatus recited in claim 1wherein the computing device comprises a laptop computer.
 4. Theapparatus recited in claim 1 wherein the computing device comprises apersonal digital assistant.
 5. The apparatus recited in claim 1 whereinthe computing device comprises a cellular device.
 6. The apparatusrecited in claim 5 wherein the plurality of gadgets comprises arespective plurality of inline frames comprising separate pages, eachwith its own uniform resource locator (URL).
 7. The apparatus recited inclaim 6 wherein the gadgets comprise Hypertext Markup Language (HTML) orJavaScript code employing Asynchronous JavaScript and XML (AJAX)requests to get data, or Java Server Pages (JSP) content to acquire datafrom the servers.
 8. The apparatus recited in claim 6 wherein eachgadget communicates or interacts with other gadgets on the same webpage.
 9. The apparatus recited in claim 1 wherein respective ones of thegadgets export specific methods that are used by other gadgets.
 10. Theapparatus recited in claim 1 wherein each gadget exists inside arespective iFrame.
 11. The apparatus recited in claim 1 wherein contentsof the iFrame object are provided via a Uniform Resource Locator (URL).12. The apparatus recited in claim 1 wherein each respective gadgetcomprises software code that calls JavaScript methods in other gadgetsvia an iFrame object array of the web page.
 13. The apparatus recited inclaim 1 wherein contents of the gadgets and the framework reside in thesame domain and the gadget points to a specific frame object of anothergadget from a frames object array.
 14. The apparatus recited in claim 1wherein methods having a form iframeObject.method (param1, param2, etc.)are accessed by one of the gadgets.
 15. The apparatus recited in claim 1wherein data are passed from one gadget to another as parameters. 16.The apparatus recited in claim 1 wherein data are communicated betweengadget iFrames by controlling session Ids of frame objects on the webpage and by passing IGC objects between gadgets.
 17. The apparatusrecited in claim 1 wherein each of the gadgets further includes an IGCcategory ID generated automatically only upon creation of a newcorresponding IGC category.